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(54) System and method for integrated circuit design 



(57) A software suite supporting a methodologies- 
based approach for the development of large scale inte- 
grated circuits. Platforms are configured as web servers 
(2503) so that they may be easily accessed by design- 
ers in widely-varying physical locations and with widely- 
varying computer workstation capabilities. 

A suite of methodologies is defined for each block 
(101, 103, 105, 107, 109, 111) of an integrated circuit 
(1 00). This suite is defined by expert designers, through 
the use of an interface, who enter information regarding 
the steps and tools (2300-2306) to be used during 
design of the blocks (1 01 , 1 03, 1 05, 1 07, 1 09, 1 1 1 ). The 
expert designer provides whatever documentation is 
deemed appropriate to aid in completion of the steps. 

For each block (101, 103, 105, 107, 109, 111) 
within an integrated circuit (100), an expert designer 
attaches a methodology or set of methodologies in an 
ordered fashion to a block (101, 103, 105, 107, 109, 
111). These methodologies are then used by block 
designers to design and implement the block. 

The invention provides extensive reporting capabil- 
ity regarding the status of development of each block, 
as well as metrics pertaining to the implementation of 
the design. These metrics include, for example, infor- 
mation pertaining to the run time of various tools, the 
time taken to accomplish each methodology, as well as 
each step in that methodology. 

The invention also includes a common software 
interface (CSI). The CSI defines a number of functions 
which are to be supported by each tool (2300-2306) 
used within the system. The functions allow other tools 
within the system to access data or information from 
other tools. 
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Description 

[0001] This application relates generally to inte- 
grated circuit design systems and methods, and more 
particularly to an environment for designing integrated s 
circuits. 

[0002] Integrated circuits have become increasingly 
complex, and perform ever increasing functions. 
Indeed, integrated circuits on a single chip now often 
perform functions which were previously performed by 10 
sets of chips or even by one or multiple circuit boards. 
As single chip integrated circuits now perform functions 
previously performed by entire systems, these single 
chip integrated circuits are sometimes referred to as 
system-on-chip (SOC). 15 
[0003] Complex integrated circuits, particularly 
SOCs, are often designed in terms of blocks, with a 
number of blocks making up the integrated circuit. The 
large number of blocks on a single chip, and the com- 
plexity of each of the blocks, increases the difficulty of 20 
the design and test of the integrated circuit as a whole. 
FIG. 1 , for example, is an illustration of an integrated cir- 
cuit 1 00. As shown, the integrated circuit (IC) consists of 
multiple interconnected blocks 1 01 , 1 03, 1 05, 1 07, 1 09, 
111. Each block typically contains complex circuitry per- 25 
forming complex functions. As illustrated, the integrated 
circuit of FIG. 1 contains six blocks. In actuality, an inte- 
grated circuit will generally contain many more blocks 
than illustrated, and will include PAD and PORT cells for 
the reception and transmission of signals from and to 30 
the integrated circuit. The use of six blocks in the inte- 
grated circuit 100 of FIG. 1 is meant to illustrate that an 
integrated circuit 100 may contain a plurality of blocks. 
Block 1 1 01 of the integrated circuit of FIG. 1 is a block 
designed and tested specifically for the integrated cir- 35 
cuit. Block 2 1 03 is a block provided by a third party sup- 
plier. Block 3 105 is a proprietary block reused from 
another design from the same manufacturer, and block 
4 1 07 is a block designed and tested by a remote design 
team. Thus, the integrated circuit of FIG. 1 includes 40 
blocks developed specifically for the integrated circuit 
1 01 , blocks derived from third party sources, blocks pre- 
viously developed in-house 105, and blocks designed 
by remote design teams 1 07. 

[0004] For the integrated circuit to function properly 45 
each of the blocks must work with the other blocks in an 
integrated fashion. In addition, it is desirable that opera- 
tion of the integrated circuit 100 as a whole be verified 
prior to actual construction of the physical circuit. 
Accordingly, each of the blocks must be supported by a so 
testing tool used to verify the functionality of the inte- 
grated circuit as a whole. In other words, the methodol- 
ogies used in the design and tests of each of the blocks 
independently should preferably have been done using 
the same methodologies, and at a minimum must have 55 
been accomplished using non-contradictory methodolo- 
gies. 

[0005] Use of contradictory (different) methodolo- 



gies is likely to result in substantial rework further along 
in the design process. For example, a chip may be 
designed using a specific file format for mask layers. A 
remote design team, however, may provide a block 
using a different file format for the mask layer, resulting 
in an unuseable block. 

[0006] In order to design and test such an inte- 
grated circuit within schedule, multiple design teams in 
geographically distant locations may be used to imple- 
ment and test the design. In addition, it is desirable to 
reuse existing blocks, sometimes referred to as block 
intellectual property (IP), in order to decrease design 
time and to reduce design associated costs. When 
implementing a design containing 10,000,000 to 
25,000,000 gates, the reuse and modification of IP 
blocks becomes increasingly attractive. Once a block 
has been developed at great expense and effort it is 
desirable to reuse that block at a later time. 
[0007] The use of geographically distant design 
teams and the reuse of block IP presents several prob- 
lems. A number of design tools, or methodologies, are 
available to assist designers in the design process, and 
the complexity of the designs often mandates the use of 
such tools. The use of different tools by different design 
teams during the design process may result in an unus- 
able design. Similarly, the design and test of previously 
designed blocks may also have utilized different tools, 
also resulting in an unusable design. Further, design 
and test tools often require that certain environmental 
parameters be assigned. Use of the same tools, but 
with differing environmental parameters, may also result 
in unworkable or unusable designs. 
[0008] The determination of the tools and environ- 
mental parameters to use in designing an integrated cir- 
cuit require a great deal of skill and knowledge, often 
gained by experience. Thus, the use of the tools is 
sometimes hampered if an individual designer does not 
have sufficient experience with the various tool sets or 
their use. Accordingly, design teams often heavily rely 
on a few specific highly skilled individuals to determine 
the design flow. The loss of such highly skilled person- 
nel during the design process may inordinately impair 
the effectiveness of the design team and result in delays 
in producing the integrated circuit. Work on further inte- 
grated circuits may also be delayed due to the lack of a 
sufficient number of highly skilled personnel. 
[0009] The use of geographically distant design 
teams and the use of IP blocks, which may have been 
developed by third party developers, also presents man- 
agement problems. The use of distant design teams 
may result in difficulties in accurately assessing the 
progress of the various design teams and their allotted 
tasks. Monitoring the design teams to ensure that the 
appropriate tools and environmental parameters are 
being used is also difficult. 

[0010] Using the Internet, networks may be con- 
nected with each other over a distance using protocols 
such as Transmission Control Protocol (TCP) and Inter- 
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net Protocol (IP). Each of the networks may be com- 
prised of a number of servers, and each network may 
be an intranet, which is separated from the rest of the 
Internet, for example, by a firewall that prevents unau- 
thorized access into the intranet. Thus, over the 
intranet, various servers for various different tasks com- 
municate with clients at remote locations. 
[0011] The World Wide Web (WWW), in particular, 
is useful for linking information between remote groups. 
Information on the WWW is typically organized and 
viewed as web pages which may contain multimedia 
elements including text, graphics, sound and animation. 
To create web pages, a markup language called Hyper- 
text Markup Language (HTML) is typically used 
although a markup language called Extensible Markup 
Language (XML) is also beginning to be used. 
[0012] The web pages are typically viewed using a 
web browser running on individual computers. The web 
browsers are capable of interpreting HTML commands 
in order to display or otherwise process text, graphics, 
sound, animation and other multimedia elements. The 
web pages are usually located on a host server called a 
web server The location of each web page is defined by 
a Universal Resource Locator (URL). The web browsers 
communicate with the web server using a protocol 
called Hypertext Transfer Protocol (HTTP). To access a 
particular web page, the web browser running at an 
engineering workstation works as a client and sends the 
URL request to the web server. When the requested 
web page is located on the web server, the web server 
sends the web page back to the web browser for display. 
[0013] Using a browser, a database is accessed 
through the use of Common Gateway Interface (CGI) 
script. The CGI script is a resident program on the web 
server and is often executed as a result of an action by 
a user using a web browser. Execution of the CGI script 
may, for example, cause the web server to access a 
data base to retrieve requested data, and return the 
retrieved data to the web browser. 
[0014] It is a consideration of the present invention 
to provide an environment for designing integrated cir- 
cuits. 

[0015] According to one aspect of the present 
invention there is provided an integrated design envi- 
ronment for the design and test of integrated circuits, 
the integrated circuits being comprised of blocks, com- 
prising: a plurality of computers, the computers includ- 
ing a browser for the display of pages including forms; at 
least one methodology server connected to the plurality 
of computers by a network, the methodology server 
including a page generator generating the pages includ- 
ing forms and additionally including programs respon- 
sive to submission of information from the computers 
using the pages including forms; and at least one com- 
pute server connected to the network, the compute 
server including an electronic design automation tool, 
the compute server executing the electronic design 
automation tool in response to a request generated by a 



program resident on the methodology server. 
[0016] Preferably the programs are responsive to 
submission of information comprising common gateway 
interface (CGI) programs or scripts. 
5 [0017] The pages including forms may include 
methodology capture pages which are used to capture 
executable methodologies. 

[0018] According to another aspect of the present 
invention there is provided a method of designing blocks 
10 using computers for use in integrated circuit design 
comprising: capturing a design methodology, the design 
methodology having steps, the steps including sub- 
methodologies; attaching the design methodology to a 
block; and executing the design methodology for 
is designing a block. 

[0019] According to another aspect of the present 
invention there are provided executable methodologies 
or design methodologies, comprising information on 
data management and data accessibility so that the 
20 resulting design data is properly recorded in different 
directories and is accessible to authorized users; the 
methodologies further comprise information on revision 
control and logistics with which different versions of the 
design are easily tracked while the logistics of manufac- 
25 turing flow from block designing to integration to fabrica- 
tion is planned out in a seamless manner. 
[0020] Other aspects of the invention are as defined 
in the accompanying independent claims 47, 48 and 49. 
[0021] The integrated design environment and 
30 method have the following advantages. 

[0022] Within the integrated design environment, 
different design teams at remote locations may use 
common automation tools and libraries during the 
design process. Thus, by providing a common set of 
35 tools and libraries to the different design teams, the inte- 
grated design environment averts the possibility of gen- 
erating an unusable design due to use of different 
design tools or environmental parameters by different 
design groups at remote locations. In other words, use 
40 of the common set of tools and libraries within the inte- 
grated design environment will result in compatible data 
file formats, testing requirements, and environmental 
parameters requirements between blocks designed at 
different locations. 
45 [0023] Since workers at all the remote locations will 
be using a common set of tools within the common inte- 
grated design environment, all the workers will become 
skilled at using the common set of tools and libraries. 
Thus, even if some of the workers depart from the 
so organization, the impact due to loss of particular skill 
sets is minimized. Therefore, the organization is largely 
relieved from the burden of meeting schedule while 
training new workers to use the tools. 
[0024] The integrated design environment also pro- 
55 vides for automated documentation and scheduling with 
which each of the remote design teams may monitor 
progress of other design teams and to schedule their 
design activities to complement the design activities of 
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other design teams, resulting in concurrent engineering. 
The automated documentation and scheduling are used 
by different workers in the same design group to keep 
track of each other's progress to schedule their design 
activities in light of the design activities of other workers. 5 
[0025] A detailed description of the invention will 
now be given, by way of example, with reference to the 
accompanying drawings in which: 

FIG. 1 is a representation showing integrated circuit 10 
blocks arranged on an integrated circuit substrate; 
FIG. 2 is an illustration of an embodiment of a net- 
work architecture. 

FIG. 3 is a block diagram showing the interconnec- 
tion of remotely located workstations, design facili- 15 
ties and the hardware interconnections; 
FIG. 4 is a diagram of the primary design server; 
FIG. 5 illustrates communication between the work- 
station, web server, and compute (computation) 
server of FIG. 2; 20 
FIG. 6 illustrates four embodiments of communica- 
tion between an EDA tool and an application, 
including embodiments having a common software 
interface, in accordance with the present invention; 
FIG. 7 further illustrates inter-tool communication 25 
using a common software interface server; 
FIG. 8 illustrates a flow chart of a process of an 
embodiment of the invention; 
FIG. 9 is a flow chart of a process of designing an 
integrated circuit according to one aspect of the 30 
present invention; 

FIG. 1 0 illustrates a flow chart of a process for cap- 
turing methodologies; 

FIG. 1 1 illustrates a screen showing a sample of 
available tools; 35 
FIG. 12 is a block diagram illustrating a process of 
designing a block by executing, methodologies 
using the interface and flow control tool; 
FIG. 1 3 is a flow chart of a process of using XML as 
a methodology capture script; 40 
FIG. 14 is a flow chart of a process of selecting file 
steps that are to be associated with automatic com- 
pression and decompression; . 
FIG. 15 is a flow chart of a process of editing a file 
which may have been compressed; 45 
FIG. 16 is a flow chart of a process of executing a 
job to be included, for example, in a launch script; 
FIG. 17 is a flow chart of a process of executing a 
chain job with automatic compression and decom- 
pression; 50 
FIG. 18 is a flow diagram illustrating an embodi- 
ment of a process for creating a home page for a 
block or chip, including actions for preparing the 
block for methodology execution; 
FIG. 19 is an illustration of a chip's home page; 55 
FIG. 20 is an illustration for a block's home page; 
FIG. 21 illustrates a sample page showing available 
processes; 
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FIG. 22 illustrates a flow diagram of a process for 
executing a methodology; 
FIG. 23 illustrates a sample design flow for a meth- 
odology having multiple steps; 
FIG. 24 illustrates an editable file step; 
FIG. 25 illustrates the examination of file contents in 
a pop up window; 

FIG. 26 shows an embodiment of a screen that is 

used to report problems encountered while 

engaged in the design process; 

FIG. 27 shows a flow chart of an embodiment of a 

problem reporting process; 

FIG. 28 shows an embodiment of the screen used 

for power planning; 

FIG. 29 is an illustration of a embodiment of a net- 
work architecture in accordance with aspects of the 
present invention; and 

FIG. 30 is a flow diagram of an example of a job 
step execution. 

I. Overview 

[0026] FIG. 2 is a block diagram of a design system 
in accordance with the present invention, and provides 
a convenient reference for an overview of aspects of the 
present invention. The design system includes an in- 
house system 2501 comprised of a plurality of computer 
devices connected by an intranet. The in-house system 
is connected, through the Internet 2502, to customer 
systems 2503, 2505. 

[0027] As illustrated, the in-house system includes 
web servers 2507, archive-servers 2509, compute serv- 
ers 2511, and engineering workstations 2513. A work- 
station as defined here comprises workstations as 
typically known to those skilled in the art, PCs, note- 
book computers and any other form of computing 
device capable of being networked. 
[0028] The in-house system additionally includes a 
factory 2515 and an IP bank 2517. The factory com- 
prises locations where integrated circuits are fabricated 
(for example, a foundry where wafers are produced), 
manufacturing and assembly facilities for packaged 
integrated circuits and final circuit assemblies. 
[0029] Linking the elements of the in-house system, 
through network ports on each of the system elements, 
is an intranet 2519. In actual practice, the in-house sys- 
tem is likely to include many additional elements, such 
as non-engineering computer systems, mass storage 
devices, servers performing a variety of functions com- 
mon to networked systems, printers, and the like. For 
clarity of description, however, these additional ele- 
ments will not be discussed. 

[0030] The engineering workstations are, in the 
described embodiment, SUN SPARC stations, although 
as those skilled in the art would recognize workstations 
from a variety of manufacturers may be used instead. In 
an embodiment workstations comprise PCs such as 
desk top, or laptop computers that are typically found in 
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an office or home. The workstation includes hardware 
and software elements generally found in such worksta- 
tions. In the described embodiment, some of the work- 
stations include one of a number of design programs 
2521 used in the design of integrated circuits. The 
design programs may be one of many widely available 
from a number of companies that specialize in creating 
tools for use in designing and testing integrated circuit 
designs. As will be understood after further discussion, 
the specific design program on a particular workstation 
is not critical. 

[0031] The workstation also includes web browsers 
2523. The web browsers provide a graphical interface 
for communicating via the in-house Intranet with other 
system elements. More specifically, the web browser is 
a Hypertext Markup Language (HTML) compatible web 
browser, such as Netscape Navigator or Microsoft 
Explorer, which allows for the display of input forms for 
use by a user of the workstation. The input forms are 
provided by other system elements, specifically the web 
server 2507. As will be discussed, the input forms pri- 
marily relate to the capture of methodologies for use in 
designing integrated circuit blocks and chips, the attach- 
ment of methodologies to integrated circuit blocks and 
chips, and the execution of methodologies in the design 
of the integrated circuit blocks and chips. 
[0032] A methodology is a series of steps chained 
together to make a pre-defined design flow that is used 
for designing and implementing a chip or block design. 
Each methodology covers a significant area of a design 
process for a chip and contains self documented step by 
step flows that, if desired, invoke tools and perform a 
main design task. The methodology is captured by a 
methodologist using an interface and flow control tool. 
In an embodiment the interface and flow control tool is a 
WBE environment (administration mode) and repre- 
sents how a design flow should be run. By following the 
steps a designer is led through the design flow. 
[0033] Examples of main methodologies are pro- 
vided to clarify the concept. The pre layout methodology 
is where pre layout design considerations are quantized 
by a methodologist for use by one or more designers. 
Another methodology is floor plan based optimization. 
In the floor plan based optimization a methodologist 
enters power planning and routing guidelines as a 
methodology for a designer to follow in designing and 
laying out blocks on a chip. The floor plan based optimi- 
zation methodology guides the designer in placing and 
routing power. 

[0034] A designer at the engineering workstation 
2513 typically requests a web page containing the 
methodology from the web server 2507 using the web 
browser 2523, generally by sending a Universal 
Resource Locator (URL) to the web server. In response, 
the web server sends the requested methodology web 
page to the engineering work station. Upon receiving 
the requested methodology web page, the designer at 
the engineering workstation may execute tools associ- 



ated with job steps of the methodology. 
[0035] The tools associated with job steps in the 
methodology may be executed in one of two modes, 
interactive mode and batch mode. In the interactive 

5 mode, the designer at the workstation may view and 
interact with each tool being executed in the compute 
server 251 1 . In a batch mode, a batch job is performed 
by the compute server 251 1 . The designer may have an 
option to execute tools in either the interactive mode or 
10 the batch mode. When the web server 2507 receives 
the request to execute the methodology steps in either 
mode, the web server executes CGI scripts to request 
the compute server to execute the tools from a method- 
ology directory structure. Version controlled data may 

15 also be stored; for example, in the archive server 2509. 
[0036] The methodology also defines the logistics 
of taking the design to fabrication at the factory 2515. 
The design data is received at the factory 2515 and 
used for fabrication of integrated circuit chips along with 

20 other technical data, e.g., IP blocks, from the IP bank 
2517. The design methodology is also used to provide 
, data to the archive server version control to ensure that 
important design data is available at later times. 
[0037] In practice, management of data associated 

25 with a methodology is accomplished using a directory 
structure. For example, in one embodiment of the 
present invention, each methodology attached to a 
block of an integrated circuit chip has its own directory 
structure. In this embodiment, each block has its own 

30 directory structure to help transfer data from one meth- 
odology to the next. The library files that support EDA 
tools have their own directory structure as well. In addi- 
tion, each integrated circuit chip has its own directory 
structure to keep information that is common to all the 

35 blocks in the chip. By using these directory structures, 
same type of design data is always placed in the same 
directory, and this enhances efficient data management 
and revision control. 

[0038] Use of captured methodologies in an inte- 
40 grated design environment and use of the pre-defined 
directory structures also improves data accessibility. 
Any member of any one of the remote design groups 
may access the design data in any of the archive serv- 
ers on the network by sending a request from his web 
45 browser to the web server connected to the archive 
server. As design data is located in a defined directory 
structure, the web server knows where to find the 
requested design data. 

[0039] A sub-methodology is effectively the same 
so as a methodology, consisting of a series of steps mak- 
ing a predefined flow. However, sub-methodologies 
cannot be run standalone. They require a calling meth- 
odology. Sub-methodologies are used wherever "some- 
thing" is common to several 'main' methodologies. 
55 Making the "something" a sub methodology results in 
less duplication and easier maintenance. Examples of 
such a sub-methodology are Delay Calculation and 
Static Timing Analysis. 
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[0040] The web server, therefore, provides input 
forms, over the intranet, to designers at workstations. 
The designers, in response to some of the input forms, 
provide information for use in executing a methodology. 
The same or other designers, in response to other of the 5 
input forms, select methodologies for use, and the order 
of use when appropriate, in designing an integrated cir- 
cuit block. The same or still other designers, in response 
to still other of the input forms, work on steps of the 
methodologies, including executing design tools or pro- ) 0 
grams such as the design program resident on the engi- 
neering workstation. 

[0041] Accordingly, the web server communicates 
HTML forms with the engineering workstation in accord- 
ance with the Hypertext Transfer Protocol (HTTP), and 15 
receives information from the engineering workstations. 
The web server utilizes a Common Gateway Interface 
(CGI) to receive data from the engineering workstations 
and to thereafter appropriately process the received 
data. The CGI is a standard for interfacing external 20 
applications with information servers, such as web serv- 
ers. A CGI program, which is also called a CGI script, is 
generally written in programming languages such as 
C++ or Perl. 

[0042] Some of the data provided by the designers 25 
is, in the described embodiment, stored and processed 
by a Unix process on the web server. For other data, 
such as a request to execute a design program or tool, 
the web server provides appropriate information to the 
workstations or the compute servers 2511, which 30 
include design programs for execution, so that the work- 
station or compute server will execute the design tool, in 
a proper configuration and with appropriate data. In 
addition, the web server transfers important data to an 
archive server to increase system reliability. The archive 35 
server is used to store files for back up. These files are 
generally not immediately needed, and in an embodi- 
ment the archived files are compressed as previously 
decided by a methodologist. 

[0043] Upon completion of the design of the inte- 40 
grated circuit or block, design details are provided by 
the web server to the factory for fabrication of the inte- 
grated circuit, or to an IP bank to allow other designers 
use of the designed block. In addition, the web server is 
linked via the Internet to customers 2503, 2505. The 45 
customers may therefore be at almost any geographic 
location, allowing designers to be located at great dis- 
tances. 

[0044] Thus, the system of FIG. 2 provides for 
orderly design and test of integrated circuits by groups so 
of designers, who may be diversely located, but are 
coordinated using the web server. In order to more fully 
comprehend aspects of the systems and methods of the 
present invention, portions of the system of FIG. 2 and 
alternative embodiments thereof are discussed in 55 
greater detail below. 



II. System Description 

[0045] FIG. 3 is a block diagram showing the inter- 
connection of remotely located workstations 201 , 203, 
205, 209 and compute servers 207, 21 1 connected to a 
primary design server 213 or a mirrored design server 
215. The primary design server and the mirrored design 
server are also sometimes termed as web servers, or 
methodology servers. The workstations, the compute 
servers and the design servers are used to design and 
test integrated circuits. The primary design server con- 
tains information pertaining to methodologies and 
blocks under design. The compute servers contain exe- 
cutable tools used in the creation and test of those 
designs. It should be noted, however, that in alternative 
embodiments the executable tools reside on the work- 
stations, and in one embodiment the primary design 
server additionally functions as a compute server. In 
addition, in one embodiment each tool resides on a sep- 
arate compute server. The workstations, which through 
the use of the Internet or intranets may be located at 
remote geographical locations from the primary design 
server, are used by design engineers to design the 
blocks. The design and test engineers utilize the work- 
stations to access data and information regarding the 
blocks, to provide data and information for execution by 
the tools, and to otherwise communicate with the pri- 
mary design server regarding the design of the blocks. 
[0046] The primary design server and the mirror 
design server are interconnected and share data so as 
to allow increased throughput and access to design 
data and processes. In one embodiment the mirror 
design server is a classic mirror server, that is the mirror 
design server mirrors the information and data of the 
primary design server. In the one embodiment the pri- 
mary design server and the mirror design server are 
substantially as easily accessible to any workstation, 
with access to the design servers substantially invisible 
to users at the workstations. In the described embodi- 
ment, however, the mirror design server is a geographi- 
cally remote server from the primary design server. 
Mirroring is accomplished by having the primary design 
server and the mirror design server periodically, e.g. at 
predefined hours, interrogate the other server to deter- 
mine if data on the other server has been updated. In 
one embodiment this is done for all data resident on the 
other server. In alternative embodiments, data updates 
only occur if data has changed with respect to specific 
blocks. Thus, if, as in the described embodiment, infor- 
mation pertaining to a specific block is located in spe- 
cific directories on a design server, then only changes in 
those directories are provided to the interrogating 
server. This allows a convenient mechanism for sharing 
of data for blocks designed by design teams remote 
from one another, as well as for periodically updating 
block information designed at remote locations to a 
location responsible for overall chip design. 
[0047] FIG. 4 is a block diagram of one embodiment 
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of a design, i.e.. web or methodology, server. In the 
described embodiment, the design server is a UNIX 
machine running an Apache web server. The design 
server includes an interface and flow control tool 31 5. In 
one embodiment of the invention, the interface and con- 5 
trol tool is used to define methodologies for designing 
integrated circuits, attach a set of methodologies to a 
specific chip or block, and provide for the execution of 
the attached methodologies to achieve implementation 
of the chip or block. In other words, the interface and w 
control tool provides an executable design environment 
for the design of integrated circuits. 
[0048] The interface and flow control tool encom- 
passes HTML pages and CGI scripts. The HTML pages 
include input forms for defining methodologies, includ- 15 
ing steps of methodologies, as well as chip and block 
home pages and executable methodologies. The CGI 
scripts receive and act on data input to the input forms 
to create files defining methodologies, chips and blocks, 
and executable methodologies attached to chips and 20 
blocks. The CGI scripts also cause execution of elec- 
tronic design automation (EDA) tools residing on the 
compute servers (illustrated in FIG. 2). 
[0049] Accordingly, the design server contains files 
303. The files are created by the CGI scripts in 25 
response to input to the input forms applying new meth- 
odologies, and responsive to input to input forms attach- 
ing methodologies to chips or blocks. In addition, in one 
embodiment the files include files and libraries compris- 
ing design data formed as the result of the execution of 30 
the EDA tools. Storing the files and libraries in one loca- 
tion allows for a systematic approach to access and 
maintainability of design related information. In addition, 
in one embodiment the files are stored in varying direc- 
tories. Storing the files and libraries in varying directo- 35 
ries allows, for example, for specific chips or blocks- to 
utilize subsets of commonly used files by first looking in 
specific directories for files prior to looking in a common 
directory. 

[0050] FIG. 5 illustrates communication between a 40 
workstation 1401, a web server 1403, and a compute 
server 1405. In FIG. 5, the workstation 1401 is identified 
as computer no. 1, and includes a web browser 1401. 
The web browser includes a location identifier area 
1409 and a display area 1411. An exemplary location 45 
identifier area is a web server with resident HTML code. 
In an alternative embodiment the location area identifier 
is a web server with resident XML code. The worksta- 
tion transmits information in HTTP format to the compu- 
ter identified in the location area. In FIG. 5, the location 50 
area of the workstation contains the URL of the web 
server, which is identified as computer no. 1 . 
[0051] More specifically, the contents of location 
area of the workstation points to an HTML file located 
on the web server. In response to the request from the 55 
workstation, the web server provides the HTML file to 
the workstation, which thereafter displays a web page 
based on the HTML in the display area. In the example 



of FIG. 5, the display page includes an input form. The 
input form includes an input section which provides an 
option for the execution of a design tool. Selection of the 
option results in transmission of a message from the 
workstation to the web server requesting execution of a 
CGI script or program. 

[0052] The CGI script executing on the web server 
forms a request for execution of a design tool on a com- 
pute server, identified as computer no. 3 in FIG. 5. Pref- 
erably, the design tools execute in that batch 
environment, thereby allowing the CGI program to com- 
plete and return status to the workstation. The web 
server receives the result of the design tool and trans- 
mits the results to the workstation through the HTML 
interface. Thus, the designer at the workstation is able 
to perform his design task using the web browser and 
does not have to leave the web browser to utilize a 
design tool. 

[0053] The status of methodology supplied to the 
workstation is typically provided in a form of status 
reports. The status reports are generated based on 
information stored with respect to the methodologies. 
While executing the design methodologies, the design- 
ers and versions of the design data are automatically 
documented as part of the»methodology execution. For 
example, based on files stored in the methodology 
directors status of a methodology is known. This capa- 
bility allows concurrent engineering by multiple individu- 
als or groups since the individuals and the groups are 
able to ascertain status of a design. In addition, the 
designers may view the schedule of other designers, 
and schedule their work so that their joint efforts will 
result in truly concurrent engineering even though they 
may be located far away from each other. 
[0054] In an alternative embodiment, the design 
tool is executed in real time, with the execution of the 
design tool being displayed to a designer at the work- 
station using an X window. FIG. 6 illustrates four com- 
munication methods used by alternative embodiments 
of the present invention. Each of the four embodiments 
include an electronic design automation (EDA) tool 
2301 in communication with an application 2309. The 
application may be, for example, another EDA tool. The 
EDA tool may, for example, be a Verilog reader which 
reads a Verilog file and provides the information con- 
tained in the Verilog file to an application. The applica- 
tion may, for example, utilize the information from the 
Verilog file to compile the design into representative 
hardware elements. 

[0055] In a first embodiment 2300, the EDA tool 
provides an output file 2303. The output file is in a for- 
mat defined by the EDA tool. The application, however, 
is likely to require an input file of a different format. 
Accordingly, a format converter 2305 is used to convert 
the output file to a format acceptable to the application. 
In a second embodiment 2302, the EDA tool once again 
creates an output file. The output file, however, is pro- 
vided to a parser. The parser extracts data from the out- 
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put file and provides the data to a data model 231 7. The 
data model places the data in a data structure. A CSI 
(common software interface) server is used to access 
the data structure to provide the correct behavior indi- 
cated by the CSI specification. 
[0056] The application obtains data through a 
request to the CSI server. More specifically, the CSI 
server supports defined interfaces. The CSI server and 
the interfaces are identified by unique identifiers. A cli- 
ent wishing to use an interface implemented by the CSI. 
server issues a request for the server and the interface. 
If the CSI server supports the defined interfaces, then 
the CSI server provides a common virtual function table 
to the application. The virtual function table points to vir- 
tual functions, and the virtual functions may be called by 
indexing into the virtual function table. The application 
thereafter uses the virtual function table to obtain data 
from the CSI server using the interfaces supported by 
the virtual function table. In addition, the first entry of the 
virtual function table is for a function allowing the client 
to request additional interfaces from the CSI server. 
[0057] In aspects of the present invention, data pro- 
vided to or received from EDA tools and the like pertain 
to integrated circuit designs. Thus, interfaces for 
requesting data pertaining to integrated circuit designs 
are supported by the CSI server. In one embodiment of 
the present invention, the data includes net data, mod- 
ule data, and pin data. Net data is data pertaining to the 
interconnection of gates, cells, modules, blocks or other 
identifiable sets of gates. Thus, examples of net data 
include a bit or a bus, or any interconnection between 
functional units. Modules have nets and pins and 
instances. Pins are simply points to which nets, or wires, 
are attached. 

[0058] Accordingly, the CSI server supports net 
interfaces, module interfaces, and pin interfaces. In 
addition, the CSI server supports additional interfaces 
pertaining to generally communication with the CSI 
server. 

[0059] The net, module, and pin interfaces contain 
functions which allow access to enumerators of their 
sub-objects; i.e. interfaces with a consistent set of meth- 
ods that allow a client to access sequentially members 
of a list. The enumerator types include interfaces for 
obtaining a list of names, a list of modules, a list of nets, 
a list of component instances, a list of pins, and a list of 
properties. The methods return, for example, a module 
to which a net belongs, a list of pins to which a net is 
attached, the type code of a pin, and other similar infor- 
mation. 

[0060] FIG. 6 illustrates a third embodiment 2304. 
In the third embodiment an API 2317 specific to the 
EDA tool is used to extract data from the EDA tool data- 
base 231 9. The API for the EDA tool is, however, propri- 
etary to the EDA tool, and does not necessarily provide 
data in a format suitable for the application. Accordingly, 
the third alternative embodiment includes a data model 
object to obtain appropriate data from the API, and to 



create data structures appropriate for use by the CSI 
server. 

[0061] FIG. 6 also illustrates a fourth embodiment 
2306. In the fourth embodiment, both the EDA tool sup- 
5 ports the common software interface. Accordingly, the 
CSI server acts as a reader to obtain data from the EDA 
tool, and acts as a writer to provide data to the applica- 
tion. 

[0062] FIG. 7 illustrates an example of a tool com- 
w municating with a plurality of other tools using a com- 
mon software interface server. As illustrated in FIG. 7, a 
tool A 2203 provides output which is utilized by a tool B 
2205, a tool C 2207, and a tool D 2209. The output of 
tool A is provided to a common software interface client 
15 2201, which includes both client and server. The com- 
mon software interface server interfaces with each of 
the tools B, C, and D. 

[0063] FIG. 29 illustrates a network design system 
in accordance with aspects of the present invention. 

20 The network design system includes a first network 
2405, and a first remote network 2401 and a second 
remote network 2403. The remote networks each 
include a plurality of workstations 2413, 2415, 2417 
interlinked by an intranet. Each of the workstations 

25 include a web browser, such as are available from Net- 
scape or Microsoft. The remote networks are connected 
to the Internet through fire walls. 
[0064] The network system is also connected to the 
Internet by way of a fire wall. The design network 

30 includes a design server 241 9. Connected to the design 
server by way of an intranet are a plurality of worksta- 
tions 241 3, 241 5, 241 7 such as those in the remote net- 
works. Also connected to the design server by way of an 
intranet is an archive server 2421 and a compute server 

35 2423. The archive server stores design data pertinent to 
the design of integrated circuits coordinated by the 
design server. The compute server includes both library 
and design data used by EDA tools. As illustrated only a 
single compute server is provided. In practice, a plurality 

40 of compute servers are provided, with each compute 
server executing a single EDA tool. 
[0065] Further connected to the intranet is an IP 
bank 2429 which stores block information so as to allow 
for reuse of IP blocks. Libraries and tools are also stored 

45 on a library/tool server 2427. The library/tool server 
2427 typically provides tools and/or libraries as 
requested by the web server when the particular tool or 
library is called for use in the design methodology being 
executed. Tools typically are individual executable pro- 

50 grams that allow the design methodology to perform 
pre-defined functions. The pre-defined functions per- 
formed by the tools preferably include data format con- 
version, design viewing, design analysis and gate 
simulation. A factory 2425 is also connected to the 

55 intranet, with the factory being responsible for the gen- 
eration of the physical integrated circuits. 
[0066] As illustrated, the design server includes 
design step 1 through design step n. This illustrates that 
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the design server contains information for the steps of 
designing the integrated circuit. 

III. Process Description 

5 

A. Top Level Flow 

[0067] FIG. 8 illustrates a flow diagram of a process 
of an embodiment of the invention. The flow diagram of 
FIG. 8 may be viewed as having three primary compo- io 
nents. In a first component methodologies are captured 
501 so that the methodologies are quantized and 
recorded as an executable set of steps. A second com- 
ponent comprises the attachment of various methodolo- 
gies to a specific block or chip 503. A third component 15 
consists of the execution of the attached methodologies 
to implement the design and test of the block or chip 
505. 

[0068] In step 501 of the process methodologies 
are captured. Capturing methodologies is accom- 20 
plished by presenting input pages to experienced meth- 
odologists, preferably those with expertise in the field. 
Input pages generally are Hyper Text Markup Language 
(HTML) based forms that are viewable using a standard 
web browser. The capture of methodologies can be 25 
implemented at any time. In an embodiment the capture 
of the methodologies is accomplished in a unique and 
orderly way. 

[0069] The methodologists, using the input pages, 
define a methodology. The definition of the methodol- 30 
ogy includes the tool, or tools, used in the methodology, 
the files required for use of the tool, and executable 
steps for preparing an environment for the tool and the 
execution of the tool. In addition, the definition of the 
methodology includes steps which reflect the output of 35 
tools, such as data files, or files required for tool execu- 
tion. The definition of the methodology further includes 
help files to assist in executing the methodology, and 
descriptions of the expected results of executing the 
methodology. In one embodiment the help files are exe- 40 
cutable PERL scripts. PERL is a programming lan- 
guage that is used to generate executable scripts. 
[0070] In one embodiment a methodology com- 
prises a directed acyclic graph defining the order in 
which steps of the methodology are executed. A step is 45 
one of a file, a job, information, a sub-methodology, a 
logical OR, or a logical XOR. A file step requires gener- 
ation of a file, or files, at a specified location. A job step 
indicates execution of a tool, and may include an exe- 
cutable configuration script, which is created at the time so 
of execution. The executable configuration script may 
be a shell script. A shell script includes commands that 
are interpreted/executed by a shell, which is a com- 
mand line interpretor. Thus, the shell takes commands 
programmed in shell scripts and executes them. 55 
[0071 ] A sub- methodology step indicates the step is 
a separate methodology. An information step provides 
information to a designer. A logical OR step and a logi- 



cal XOR step are branch steps that provide branching 
capability within a methodology. 
[0072] In step 503 of the process, methodologies 
are assigned, or attached, to a block. In one embodi- 
ment the methodologies define a process flow from the 
initial generation of HDL to tape out of the fabrication 
guidelines, or even fabrication of the chip itself. The 
methodologies are defined so as to include executa- 
bles. Thus, the attachment of methodologies to the 
block define an executable process flow for the design 
and test of the block. 

[0073] In step 509 the process determines if attach- 
ment of methodologies to the block is complete. Once 
complete, the process continues to step 505 in which 
methodologies are executed. In one embodiment of the 
invention, a complete set of methodologies need not be 
attached to the block prior to execution of methodolo- 
gies. Instead, further methodologies may be added 
while existing attached methodologies are added. For 
example, a front-end methodology may be executed 
prior to capturing or attaching a layout methodology. 
Thus methodologies may be assigned at any time dur- 
ing the design process to allow individual blocks to be 
redefined as required. 
, [0074] In step 505 of the process the methodolo- 
gies are executed so as to design the block. A given set 
of designers require access to the design at differing 
times of the design cycle, some of which are overlap- 
ping. A given designer, in addition to requiring access 
only at certain time, also only requires access to the 
tools and methodologies that are deemed necessary to 
carry out the task. Each person in the preselected 
design team, using the selected tools at the scheduled 
time, executes the methodologies by performing their 
portion of the work on the circuit. Executing the method- 
ologies in this manner assures that design teams that 
are located in isolation from each other perform their 
tasks at the appropriate stages without having to be in 
close contact with all the designers in their various loca- 
tions. In addition, as the methodologies are designed to 
include executable setup files and to include help files, 
the presence and assistance of highly skilled expert 
methodologists is not necessarily required to further 
facilitate design and test of the block. 
[0075] In step 507 of the process metrics and 
reports concerning the execution of the methodologies 
are generated. The metrics and reports pertain to the 
status of the design and test of the block, the results of 
execution of various steps which make up a methodol- 
ogy, problem reports, tool usage reports, and reports 
pertaining to any aspect of the execution of the method- 
ologies. In particular metrics refer to any measurement 
tool that provides quantifiable indication of a process's 
quality, progress or completion. Accordingly, during exe- 
cution of the methodologies the process tracks and 
records all actions and results of actions. 
[0076] Once the metrics and reports are generated, 
the process determines in step 51 1 if more methodolo- 
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gies remain to be executed. If more methodologies 
remain, the process of executing methodologies and 
generating metrics is continues. If no more methodolo- 
gies remain to be executed the process completes. 
[0077] FIG. 9 is a flow diagram of a process incor- 
porating aspects of the process of FIG. 8 for designing 
an integrated circuit. The process of FIG. 9 is meant to 
illustrate a specific example of a design process in 
accordance with FIG. 8: As should be clear from the 
process of FIG. 8, the actual steps performed, and the 
order of their performance, are determined when meth- 
odologies are attached to a specific block. 
[0078] In the process of FIG. 9, first a product spec- 
ification 403 is created. In this stage of the design a 
design team decides what the chip does in terms of its 
desired behavior and partitions the chip into a series of 
function blocks required. 

[0079] At step 403 the design team also evaluates 
what IP functions exist, and what IP functions will be 
required to be designed. The product specification may 
be, for example, in the form of HDL, VHDL, Verilog, or in 
other forms. 

[0080] In step 401 of the process methodologies 
are selected for use in the design of the circuit or block. 
In selecting methodologies, the designer determines 
which tools and processes are to be used in designing 
and testing the block or circuit. The tools and processes 
selected drive the steps of the design process. 
[0081] After the specification phase, a series of 
steps 405,407, 409, 411, 413, 415 are carried out that 
result in a physical design of the circuit. Each step in the 
design process may require one or more iterations until 
that stage of the design has been satisfactorily com- 
pleted. Also, after two or more steps are completed, it 
may be realized that the cumulative solution obtained at 
the stage is inadequate and must be reiterated. Tracking 
of the design process is therefore sometimes difficult 
The problems of tracking progress of the design proc- 
ess is compounded when design teams implementing 
each task are located in remote locations, making com- 
munications difficult. 

[0082] Step 405 of the process is the generation of 
a register transfer level (RTL) model. Generation of the 
RTL model is required if no preexisting block exists, 
such as when a block must be designed from scratch. 
The RTL model represents the block behavior of the 
design. The RTL model is a synthesizable behavioral 
model that is translated into a structural model providing 
a logic level description of the system. The generation of 
the RTL model is accomplished using methodologies 
previously selected. 

[0083] Step 407 of the process is the synthesis of 
the circuitry necessary to implement the logic functions 
of the RTL model. The designer synthesizes the circuit 
using a methodology including a synthesis tool. The 
methodology corresponds to one or some of the meth- 
odologies previously selected. An analysis program 
optionally may be executed as part of this step, with the 



analysis program used to verify that the output of the 
synthesis step behaves in accordance with the product 
specification. The use of the analysis program is gener- 
ally specified as a separate methodology, although it 
5 may be a sub-methodology or step of the synthesis 
methodology. 

[0084] Step 409 of the process is simulation of the 
overall design. All of the components of the design are 
assembled and a simulation is run. The simulation tool, 

10 test vector generation, and other matters are deter- 
mined by the selected methodologies. The design is 
adjusted until satisfactory simulation results are 
obtained. At this point in the design cycle, a satisfactory 
design consists of a schematic that contains compo- 

15 nents such as transistors that may be built on the inte- 
grated circuit, and that when simulated using 
appropriate models give appropriate results. These 
models generally do not take into consideration the 
physical layout of these components on the integrated 

20 circuit substrate. 

[0085] Step 41 1 of the process is placing the com- 
ponents of the design on the substrate and routing of 
signal to and from the components. Place and route is 
generally accomplished using one or more place and 

25 route tools. The place and route tools used are specified 
by the selected methodologies. The output of the place 
and route is a representation physical layout of the inte- 
grated circuit as it is built. 

[0086] Step 413 of the process is RC extract and 

30 Back Annotation. 

[0087] Step 41 5 of the process is verification of the 
design. Verification consists of ensuring that the result 
of design conforms with the product specification. Veri- 
fication is accomplished using one or more tools 

35 employing one or more techniques. The tools 
employed, and the techniques used, are specified by 
the selected methodologies. The verification step 
includes timing verification, mask verification, and often 
formal verification. Extraction of data to put back into a 

40 subsequent simulation is performed in this step. 

[0088] Step 409 is a simulation performed using 
data extracted from the previous step to perform a final 
check to ensure that the final design conforms with the 
product specification. 

45 [0089] After verification of the circuit, step 417 of 
the process is tape out. At tape out the design is final- 
ized for a prototype to be produced. To produce the pro- 
totype integrated circuit, information is generated to 
produce the semiconductor mask. The masks are sent 

so out and an integrated circuit foundry fabricates the cir- 
cuit. 

[0090] Thus, in the process of FIG. 9, the design 
process flow begins with the selection of methodolo- 
gies, and proceeds, using the selected methodologies, 
55 until fabrication of the integrated circuit is complete. Of 
course, those skilled in the art will recognize that, after 
selection of the methodologies and the specification of 
desired circuit behavior, many different design flows 
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may be used. For example, simulation and verification 
may, and often do, occur at each stage of the design 
process. Similarly, modification of the circuit design to 
allow for testing using scan chains, BISTs, and the like 
is also often generally accomplished. 5 

B. Methodology Capture 

[0091] Design methodologies, i.e., methodologies, 
for web based integrated circuit design and fabrication 10 
are captured using HTML (Hyper Text Markup Lan- 
guage) based forms that are viewable over the world 
wide web using HTTP protocol. HTML based forms, i.e., 
input pages, are provided to methodologists to be used 
during capture of methodologies. The methodologists 15 
complete the HTML based forms and submit them to 
the web, i.e. design or methodology, server to capture 
design methodologies. 

[0092] When the methodologist inputted data is 
submitted to the web server, a number of files, which 20 
comprise the captured methodology, are generated. 
Each design methodology defines an executable set of 
steps, and the generated files define the steps. Each 
design methodology will eventually be associated with 
various specific blocks and/or chips by listing it in block 25 
and/or chip home pages as one of the design methodoh 
ogies to use. The home pages also serve to order the 
execution of the design methodologies that are listed in 
them, respectively. Each design methodology may be 
associated with more than one block and/or chip. 30 
[0093] The files associated with design methodolo- 
gies include info files and index files that are used to 
maintain design methodology data. In other words, the 
info files and the index files contain information regard- 
ing steps of the associated design methodology such as 35 
name, description, type and order of execution. The files 
that comprise each design methodology also include a 
set of files associated with each step in the design 
methodology. The files that are associated with design 
methodology steps also include info files and index files 40 
associated with them. 

[0094] In an alternative embodiment, the design 
methodology data is stored in a database. The data- 
base may be in one of many various implementations. 
In one embodiment, the design methodology data is 45 
stored in an Oracle database. 
[0095] The files associated with design methodolo- 
gies preferably include an executable documentation 
file. The executable documentation file, created by the 
methodologist of the associated design methodology, so 
contains information regarding the purpose of the 
design methodology, information pertaining to a specific 
step, and/or other information the methodologist 
believes relevant. The design methodology also prefer- 
ably includes one or more executable documentation 55 
files that are associated with a corresponding step of 
the design methodology. The executable documentation 
files associated with the design methodology and the 



steps are further processed by an integrated circuit 
design and fabrication system to customize associated 
methodology step pages when they are applied to a 
block. 

[0096] The executable documentation file prefera- 
bly contains codes in a programing language such as 
Perl. When a design methodology step page is dis- 
played for a particular block, a programmable part of the 
documentation displays specific information pertaining 
to the particular block. This technique allows the design 
methodology step page to correctly provide specific 
details which may be important for certain implementa- 
tions. For example, the name of the block may be dis- 
played directly in the documentation. The executable 
documentation files and other files generated during 
design methodology capture are executed to implement 
the design and test of the associated blocks or chips. 
[0097] FIG. 10 illustrates a flow diagram of a proc- 
ess for capturing design methodologies. In step 1101 
the process provides an input page in HTML format. 
The input page at step 1101 allows a methodologist, 
typically an experienced integrated circuit designer, to 
enter details of a design methodology. The input page, 
after relevant data is filled in, is subsequently submitted 
to a web server for generation of files that comprise the 
design methodology. 

[0098] In step 1 103 the methodologist prepares an 
executable documentation file, i.e., an HTML file frag- 
ment, pertaining to the design methodology. The docu- 
mentation entered in step 1103 is meant to pertain to 
the design methodology as a whole. The methodologist 
may also provide an executable documentation file 
associated with each of the steps in the design method- 
ology. In one embodiment, comments entered in the 
executable documentation file are a series of text 
entries. In another embodiment, comments are execut- 
able PERL scripts which provide instructions and other 
items of information to designers. 
[0099] In addition, a step may be assigned depend- 
encies in terms of required files or required succeeding 
steps. In one embodiment, the interface and flow control 
tool uses the dependencies to display statuses of pre- 
ceding and succeeding steps during the integrated cir- 
cuit design process. An advisory may also be provided 
to indicate that required preceding steps have not been 
completed. Further, steps of the design methodologies 
may be results of executing one or more prior steps. For 
example, a file comprising a netlist may be a step, 
where the netlist file was generated using a tool in a pre- 
ceding step. 

[0100] In step 1 1 05 a step in the process of captur- 
ing the design methodology is selected. The process 
receives input from the methodologist who selects a 
type of step or operation to be executed in the design 
methodology being captured. In one embodiment, 
seven step types, i.e., operation types, are available for 
defining executable design methodologies: file, job, 
information, sub-methodology, logical OR, logical XOR, 
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and flow. 

[0101] In file step 1107 the process receives as 
input from the methodologist a file name and a location 
of the file. For a job step 1 109 the process receives as 
input from the methodologist a tool name to be used 5 
during job execution. 

[0102] Referring now to FIG.' 1 1 , a screen compris- 
ing names of available tools is shown. The designer is 
allowed to select an available tool. A pointer providing a 
path to the tool for execution of the tool is incorporated w 
into a design methodology along with the selection of 
the tool. The pointer may point to a location on a design 
server, e.g., the primary design server. Alternatively, in 
the embodiment described, a pointer points to a tool 
executing on a compute server. 15 
[0103] Returning now to FIG. 10, the process also 
receives in step 1 109 information pertaining to the envi- 
ronment produced by the tool. The tool environment is 
executable which, for use, configures a computer sys- 
tem and a tool. 20 
[0104] For an information step the process receives 
in step 1111 as input from the methodologist informa- 
tion which may be pertinent to the design process. For a 
sub-methodology step the process receives in step 
1 1 13 the name of a sub-methodology. Sub-methodolo- 25 
gies are design methodologies called from other design 
methodologies, and are utilized to form a more complex 
overall design methodology. 

[01 05] In steps 1115 and 1 1 1 7 the process receives 
branching options from the methodologist for OR and 30 
XOR branching respectively. A logical OR and a logical 
XOR step provide for parallel and branching paths, 
respectively, in a design methodology. For example, a 
design methodology may allow for any single one of 
several versions of a tool to be used in a job step. Pre- 35 
ceding the job step, therefore, is an XOR step providing 
for selection of the version of the tool. 
[0106] In step 1119, the process receives from the 
methodologist a list of steps to be executed within a flow 
step. The flow step is similar to a sub-methodology 40 
except that the flow step may exist only within a design 
methodology or a sub-methodology. In other words, the 
flow step may not stand alone. Thus, a flow step typi- 
cally contains multiple steps and is used to organize the 
design methodology as to reduce the number of steps 45 
called directly by the design methodology. 
[0107] After each of the steps 1107, 1109, 1111, 
1 1 1 3, 1 1 1 5, 1 11 7 and 1 1 1 9 is selected, the methodolo- 
gist selects a succeeding step to be executed subse- 
quent to the selected step. By selecting the succeeding 50 
step, the methodologist is able to define an order in 
which the selected steps are executed. The order of 
step execution is incorporated into a directed graph, i.e., 
directed acyclic graph (DAG), which is one of the files 
created when the methodologist submits information in 55 
the input page. Thus, the directed graph contains infor- 
mation on the order in which the selected steps are exe- 
cuted. Not all steps may be executed sequentially In 



other words, some of the steps may be executed in par- 
allel. 

[0108] In step 1121 the process determines if the 
methodologist desires to enter more steps. If the meth- 
odologist desires to enter more steps, the process 
returns to step 1 105, and otherwise the process termi- 
nates. In step 1 105, the methodologist selects the next 
step and the process of step selection and incorporation 
of the selected steps into the directed graph repeats. 
[01 09] FIG. 1 2 is a list of design methodologies that 
may be attached to a block home page or a chip home 
page. As indicated by option to edit each design meth- 
odology in FIG. 12, design methodologies may be 
edited after their initial creation. This editing may be 
done to add additional materials, including steps or sub- 
methodologies or to modify the design methodology. In 
addition, sub-methodologies may be separately 
selected and modified as well. 
[0110] . Methodology capture allows for design 
methodologies to be defined having parallel paths. For 
example, a design methodology may be defined such 
that several versions of a tool may be used during the 
design process. Thus, designers of the design method- 
ology, during the design process, may select any of the 
parallel tools to accomplish the design. 
[0111] During the design process, it is also possible 
that use of a tool that replaces the tool specified in the 
methodology is required. For example, a new version of 
a tool may be required for use in a design. A selective 
tool override function allows a designer to specify the 
new version, overriding the choice defined in the design 
methodology by the methodologist. By providing the 
selective tool override function, both the old and new 
versions of the tool may be used with the same method- 
ology. 

[01 1 2] During the methodology capture process, an 
executable chain job is also defined. A chain job com- 
prises a series of job steps that the methodologist cap- 
tures for execution in a specific order. Only batch job 
steps and not interactive job steps are generally in a 
chain job. 

[0113] Although HTML based forms are typically 
used to capture design methodologies, it is often more 
desirable to use XML (Extensible Markup Language) 
script to define design methodologies because of 
advantages that XML has over HTML. In XML, informa- 
tion is divided into useful components called elements, 
e.g., titles, paragraphs and part numbers. The elements 
may be formatted, sorted, or searched in a consistent 
fashion. The elements are typically named and defined 
in a computer program called a Document Type Defini- 
tion (DTD). 

[0114] Using XML, a methodologist is able to create 
a single file to describe each design methodology. The 
single file that describes the design methodology may 
be used to create other files needed to execute the 
design methodology. For example, new features can be 
added to XML over time since XML is an extensible lan- 
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guage. In addition, parsers are easy to develop using 
XML. For example, the parsers may be partially gener- 
ated automatically from the DTD. Further, XML sources 
may be scanned by various different programs for differ- 
ent purposes. For example, a source code based on 5 
XML may be scanned by a search engine. 
[01 15] Another benefit of using XML is that XML is 
capable of providing multiple language support. For 
another example, an XML file is easy to create provided 
that a good DTD has been created. In addition, an XML- 10 
based DTD file may be used to specify the internal 
nature of the XML files used to define design methodol- 
ogies. Further, XML hyper-linking is more powerful than 
HTML hyper-linking, and XML hyper-linking may be 
used to refer to parts of other XML files. 15 
[0116] Widely used web browsers may not have a 
capability to display pages having embedded XML. 
Therefore, in an alternate embodiment, rather than 
using an input page to capture design methodology, a 
methodologist creates an XML script defining a design 20 
methodology in a single file. In this embodiment, the 
XML files are used by Common Gateway Interfaces 
(CGI's) to drive the integrated circuit design and fabrica- 
tion system rather than directly viewed using a browser. 
[0117] FIG. 13 is a process of using XML as a 25 
design methodology capture script. According to the 
process in step 521, a methodologist captures a design 
methodology in a single file in the form of an XML script. 
Next, a converter with XML parsing capability is used in 
step 523 to convert the captured design methodology 30 
into multiple files including info and index files as well as 
a directed acyclic graph (DAG) file. 
[0118] As shown in step 525, the methodologist 
may update the design methodology by modifying the 
XML file. Thus modified, the XML file may be converted 35 
again into multiple files. Use of a single XML file is pref- 
erable to using multiple files generated by HTML forms 
since the single XML is easier to archive and maintain 
than the multiple files. 

[0119] The process in step 527 may convert the 40 
modified design methodology in XML format to the 
design methodology format where the design methodol- 
ogy comprises multiple files. In an embodiment of the 
present invention, a converter converts the captured 
design methodology format having multiple files to a 45 
single file having an XML script. A specification of a 
Methodology Document Type Definition (DTD) is used 
during development of these converters. 
[0120] Many of the files used during file steps and 
job steps while executing design methodologies are 50 
extremely large. Generally, these files are stored in the 
integrated circuit design and fabrication system for days 
or weeks during the chip design and fabrication proc- 
ess. 

[0121] System resources may be conserved by 55 
compressing some of the files and decompressing the 
files when needed. In an embodiment of the present 
invention, the methodologist of the design methodology 



is able to select file steps that are candidates, i.e., com- 
pressible file steps, for applying automatic compression 
and decompression during methodology capture. The 
methodologist may specify one or more of the file steps 
as compressible in the design methodology. 
[0122] Since it may take an extensive amount of 
time to compress or decompress a file, a compute 
server rather than a web server is generally used for 
compression and decompression. Thus, the web server 
is not burdened with these tasks and web pages are 
kept from timing out. 

[0123] Thus, a methodologist is given control over 
selecting which steps are compressible. In one embod- 
iment, once the methodologist selects the compressible 
file steps, the information contained in a directed acyclic 
graph (DAG) is used to automate the tedious chore of 
determining when files are to be compressed. Although 
the file compression and decompression are auto- 
mated, the integrated circuit design and fabrication sys- 
tem is preferably also capable of handling a situation 
where a designer manually compresses or decom- 
presses a file from a command line. 
[0124] In the embodiment described above, there- 
fore, none of the files associated with a particular file 
step may be compressed unless the particular file step 
is marked as compressible. Even if a file step is marked 
as compressible, some of the files associated with that 
file step may not be compressed. For example, there 
are some files that are generally excluded from com- 
pression. The files that are generally excluded from 
compression include: a) files that are already com- 
pressed; b) technology library files that should be left in 
their uncompressed form for speed; and c) files that are 
too small to benefit from compression. 
[0125] FIG. 14 is a process of selecting file steps 
that are to be associated with automatic compression 
and decompression. In step 1125, a methodologist 
determines which file steps are candidates for auto- 
matic compression and decompression while capturing 
the design methodology. Check boxes are provided on a 
step parameters edit page that is accessed by the meth- 
odologist so that the methodologist may mark the 
selected file steps. In step 1127, the methodologist 
chooses to check one or more check boxes to specify 
that the files associated with the checked file steps are 
candidates for automatic compression and decompres- 
sion. The checked file steps are called compressible file 
steps. 

[0126] A methodologist may mark some of the file 
steps as both editable and compressible. Thus, a com- 
pressed file may need to be edited. To edit a file, an 
uncompressed native version of the file is generally 
required. Therefore, a compressed file is preferably 
decompressed first before being edited. 
[0127] FIG. 15 is a process of editing a file which 
may have been compressed. The process in step 1131 
determines whether the file has been compressed. If 
the file has been compressed, the process in step 1 133 
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decompresses the file before editing it. The process in 
step 1135 edits an uncompressed file or a file that has 
been decompressed in step 1133. Once the editing is 
completed, the process in step 1137 determines 
whether the file is to be compressed. If the file is not to $ 
be compressed, the process returns. Otherwise, the 
process in step 1 139 compresses the file, and then the 
process returns. 

[0128] FIG. 16 is a process of executing a job step 
where one or more input and output files may be com- w 
pressed and/or decompressed. The process in step 
1141 determines whether an input file has been com- 
pressed. If the input file has been compressed, the 
process in step 1 143 decompresses the input file. The 
process in step 1 145 executes the job using either the 15 
uncompressed input file or the decompressed input file. 
The step 11 45 of the process may require multiple input 
files, some of which may have been decompressed. 
[0129] The process in step 1147 determines 
whether any of the input files is to be compressed. If one 20 
or more input files are to be compressed, the process in 
step 1 149 compresses these input files. The process in 
step 1 151 determines whether any of the output files is 
to be compressed. If one or more output files are to be 
compressed, the process in step 1153 compresses 25 
these output files. The process returns after compress- 
ing the output files to be compressed, if any. 
[0130] Sometimes multiple job steps are executed 
in an appropriate order. These multiple job steps com- 
prise a chain job. Since decompressing and recom- 30 
pressing the same file several times during the 
execution of a chain job should be avoided, it is more 
difficult to implement automatic decompression and 
compression when a chain job is to be executed. 
[0131] FIG. 17 is a process of executing a chain job 35 
with automatic compression and decompression. The 
process in step 1 161 determines whether any input file 
for a next level of the chain job has been compressed, 
starting with the first level. If one or more input file for 
the next level of the chain job has been compressed, the 40 
process in step 1163 decompresses the or each input 
file. The process in step 1 1 65 executes the next level of 
the chain job, starting with the first level. 
[01 32] After the next level of the chain job has been 
executed, the process in step 11 67 compresses all input 45 
files any of the decompressed input files that are not to 
be used in other levels of the chain job. In addition, the 
process in step 1167 compresses all output files that 
are to be compressed and not to be used in other levels 
of the chain job. The process in step 1 169 determines so 
whether the last level of the chain job has been exe- 
cuted. If there are more levels of the chain job to be exe- 
cuted, the process proceeds to step 1 161 and repeats 
steps 1 1 63, 1 1 65 and 1 1 67 as needed for the next level 
of the chain job. 55 
[0133] If the process in step 1 169 determines that 
the last level of the chain job has been executed, the 
process in step 1171 compresses all remaining input 



files to be compressed and all remaining output files to 
be compressed. 

C. Chip/Block Definition 

[0134] For every chip, there is an associated web 
page that resides in the design server. The web page is 
typically known as a chip home page. The chip home 
page contains information regarding the associated 
chip. The chip home page also allows access to config- 
uration changes for the associated chip. Similarly, each 
block of a particular chip is associated with a web page 
called a block home page. The block home page con- 
tains information regarding the associated block, and 
allows access to configuration changes for the associ- 
ated block. 

[0135] FIG. 18 is a flow diagram illustrating an 
embodiment of a process 600 for defining a block and a 
chip. During definition, the chip and block home pages 
provide a gateway for assigning the block its place in the 
hierarchy of the chip architecture, attaching methodolo- 
gies to the corresponding chip and the block, and gen- 
erally accessing information relating to the 
corresponding chip and the block. 
[0136] An example of a chip home page is illus- 
trated in FIG. 19, and an example of a block home page 
is illustrated in FIG. 20. In an embodiment of the inven- 
tion, a chip home page of a particular chip is linked to a 
collection of blocks comprising the particular chip. The 
designer selects which methodologies to use for a chip 
and a block from the corresponding chip home page 
and the block home page, respectively. In an embodi- 
ment a block may not be designed independently of a 
chip, due to the need for a series of signals and power 
connections of the IC that define a container for a block. 
[0137] Step 601 of the process 600 of FIG. 1 8 is the 
initialization of a chip definition. Information regarding 
the chip is viewed through the chip home page, which is 
used during chip definition. For example, as illustrated 
in FIG. 19, a chip home page includes the name of the 
chip, links to pages concerning the chip, methodologies, 
library search override definition of power groups, gen- 
eral information, tools and tool override. These parame- 
ters are assigned by a designer during chip definition. A 
chip home page also contains a list of the blocks in the 
chip, as well as the methodologies currently in use for 
the blocks. In addition, the chip home page includes 
other useful information, such as information required 
for a process. 

[0138] In step 603 of the process 600, a process to 
be used for fabricating the chip and a version for the 
process is selected. Then the process is suitably config- 
ured for the chip. A single process generally applies to 
all blocks of a chip. Certain of the methodologies may 
only be available for certain specified processes, and 
versions of processes. For example, a methodology 
associated with a .35 micron technology process may 
be unsuitable for a process associated with a .25 micron 
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technology process. Generally, the process is selected 
on a chip level basis. FIG. 21 illustrates a sample page 
showing available processes and their versions. 
[01 39] In step 605 of the process 600, methodolo- 
gies are attached to the chip. The chip home page lists 
attached methodologies to the chip. Initially, the list of 
methodologies is empty. A designer uses the chip home 
page to attach the selected methodologies to the chip. 
[0140] Each methodology generally has a corre- 
sponding tool selection menu. In one embodiment the 
chip home page allows for tool selection, and the 
selected tools become the default tools for all blocks ref- 
erenced by the chip. In step 607 of the process 600, the 
designer of the chip selects tools from the tool selection 
menu after attaching the corresponding methodology to 
the chip. 

[0141] The Common Gateway Interface (CGI) 
receives chip and block home page data from the engi- 
neering workstations to generate a block directory that 
appropriately processes the received data in the direc- 
tory to activate to implement selected available tools. In 
the block directory the technology product is assigned a 
block for each configuration created. Additionally, the 
chip and block home page data may be saved into a 
database as well. 

[0142] In step 609 of the process, a block definition 
is initialized. A block home page used during block defi- 
nition includes the name of the block, a process used by 
the block, search path override, reference blocks (or 
child blocks), power groups, methodologies used on the 
block, a list of and an access to perform a tool override 
selection. The block home page also includes links 
regarding the chip, the block, general items, and tools. 
Selection of a tool on a block home page overrides any 
tool selection accomplished on the chip home page for 
that block. 

[0143] In step 611 of process 600, a technology 
product is selected for a particular block. The technol- 
ogy product may be a Field Programmable Gate Array 
(FPGA), standard cell or gate array or any other product 
suitable for the particular block. Once selected, the 
technology product may be configured. For example, 
configuring the technology product may comprise defin- 
ing the number of metal layers. 

D. Methodology Execution 

[0144] FIG. 22 is a block diagram illustrating a proc- 
ess 1500 of designing a block by executing methodolo- 
gies, i.e., design methodologies, using the interface and 
flow control tool. Once chip and block have been initial- 
ized and configured on the methodology server, they 
are accessible from any workstation that has a browser. 
Thus, in step 1501 the block or chip home page is 
accessed to begin the design process. 
[0145] Once the chip or block home page has been 
accessed, the designer determines the status of the 
design, and whether the task desired to be accom- 



plished by the designer is ready to commence. When 
the designer selects a methodology from either a block 
home page or a chip home page, the web server runs a 
Common Gateway Interface (CGI) program associated 

5 with the selected methodology. The CGI program first 
displays an executable documentation file, i.e., HTML 
file fragment associated with the methodology. If the 
executable documentation file includes proper PERL 
programming, the CGI program may display pro- 

10 grammed information on a methodology page. The 
designer may check the status of the work to determine 
what steps are currently being performed by others and 
what remains to be done. 

[0146] In step 1503 of the process 1500, the 

is designer selects a step from a list of steps available 
from the methodology page. The designer may select 
any step displayed on the methodology page. Each step 
is generally illustrated on the methodology page as a 
step name surrounded by a rectangular box. 

20 [0147] FIG. 23 is a methodology page that illus- 
trates a sample design flow for a methodology having 
multiple steps 1600. The illustrated design flow repre- 
sents contents of the associated directed acyclic graph 
(DAG) that contains information on the names of the 

25 steps to be executed as well as the order of execution. 
The design flow includes multiple steps. Some of the 
steps are executable tools 1601 , 1 603, 1 605, and some 
of the steps are output files 1607, 1609, 1611 which 
result from execution of the tools. 

30 [0148] Arrows 1611, 1613 show dependencies 
between steps of the flow. Not all steps are executed 
sequentially. In other words, some of the steps may be 
executed in parallel. In the embodiment shown in FIG. 
23, the colour of each box surrounding a step indicates 

35 the status of the step. For example, in the embodiment 
described, completed steps are of a first color 1 61 5 and 
uncompleted steps are of a second color 1 617. In other 
embodiments, a set of icons are provided for indicating 
step status. In addition, job steps are indicated with bold 

40 lines 1601, 1603, while other steps, such as the pres- 
ence of output files, are not so indicated. In other 
embodiments, different step types are indicated by dif- 
ferent graphic types. 

[0149] By selecting one of the boxes, the user 
45 accesses the associated step for that block for that chip. 
In one embodiment, the associated step may define a 
chain job. In a chain job, due to dependencies in meth- 
odologies, the interface and flow control tool, on com- 
mand, automatically queues and provide queue control 
so for a number of job steps, ordering the job steps based 
on the flow of the methodology and waiting, as neces- 
sary, for the creation of required files. 
[0150] FIG. 24 is a methodology step page 1700 
that shows the result of selecting a file step. Selecting 
55 the file step causes the methodology step page to be 
displayed. The methodology step page provides docu- 
mentation regarding the nature of the file step. In addi- 
tion, the methodology step page corresponding to a file 



15 



29 



EP 1 063 599 A2 



30 



step includes an archive button and an edit button. The 
archive button is used to handle options associated with 
archiving files. The edit button is used to edit all files 
associated with the file step. Further, in one embodi- 
ment, the designer may click on the file name to down- 
load file step information to view on the designer's 
workstation. 

[0151] For example, the methodology step page of 
FIG. 24 displays information regarding a Verilog netlist 
file. In this particular embodiment, the methodologist 
has specified that this file may be edited. Thus, there is 
an edit button on the methodology step page. There- 
fore, the Verilog netlist file may be edited when the 
designer presses the edit button. FIG. 25 is the Verilog 
netlist file in an editor which is deployed as a pop-up 
window when the edit button is pressed. 
[0152] Similarly, FIG. 28 illustrates a methodology 
step page displayed as a result of selecting an informa- 
tion step regarding power planning, which is imple- 
mented as a flow step. Power planning, alternatively 
referred to as floor plan based optimization, is a previ- 
ously entered methodology to aid a designer in routing 
power and ground connections between blocks and to 
outside integrated circuit pins. In the floor plan based 
optimization, a methodologist enters power planning 
and routing guidelines as a methodology for a designer 
to follow in designing and laying out blocks on a chip. 
The floor plan based optimization methodology guides 
the designer in placing and routing power. The power 
planning methodology is primarily intended as a set of 
design rules recorded to aid a designer in laying out the 
power and ground connections. 
[0153] Returning now to FIG. 22, thus in step 1503 
the interface and flow control tool provides for selection 
of a step or methodology. The designer may also make 
other selections at this step. The designer may opt for 
guided instructions, or recording of tool environment 
commands or the selective override of a tool at the block 
of chip level. 

[0154] As previously discussed, selection of a step 
results in the web server providing the designer a page 
for that step. For a job step, if the job step is set for exe- 
cuting as a batch job on a compute server, the page 
includes a selection of a compute server. A selection of 
a compute server causes the. web server to request exe- 
cution of the batch job on the compute server. 
[0155] In order to more fully describe aspects of the 
present invention, steps taken by the program on the 
web server to result in execution of the batch job on the 
compute server are discussed with reference to FIG. 
30. FIG. 30 illustrates a process of providing for execu- 
tion of a job step in batch mode. The process is exe- 
cuted at the methodology server. As the process 
executes in response to input from a web based input 
form, the process is a CGI program. In summary, the 
web server maintains information provided by method- 
ologists during a capture of the methodology pertaining 
to the job step. The information includes a tool to be 



used, the location of files upon which the tool is to act, 
other parameters to be provided to the tool, and execut- 
able environment code for properly configuring the com- 
pute server for execution of the tool. 

5 [0156] Accordingly, in step 2601 the process pre- 
pares a file to be provided to the compute server for 
execution on the compute server. The file includes gen- 
eral purpose environment variables, i.e. global varia- 
bles, for configuring the compute server. The global 

10 variables are of a general nature, and are defined in a 
preset file on the methodology server. In step 2603 the 
process includes in the file values for environment vari- 
ables stored in a second file on the methodology server. 
The values stored in the second file of the methodology 

15 server are unique to a specific methodology server, and 
allow for a methodology server administrator, for exam- 
ple, to additionally configure compute servers. In step 
2605 the process examines the database, or specific 
files depending on the implementation, for the environ- 

20 ment code provided by the methodologist As previously 
discussed, during methodology capture the methodolo- 
gist is able to determine the environment in which a job 
is to execute by including executable configuration code 
to configure a compute server. In step 2607 the process 

25 sets the status of the job as ready to run. The status of 
the job is used to display to designers the status of the 
design tasks. In step 2609 the process additionally 
examines the database, or the files depending on the 
implementation, to build a command line to execute the 

30 tool. The command line includes locations of files and 
the like as determined by the methodologist during 
methodology capture. In step 261 1 the process trans- 
mits the file, which is an executable script, to the com- 
pute server to provide for execution of the job step. The 

35 process thereafter returns. 

[0157] While a step of a methodology is being 
worked, the interface and flow control tool also prevents 
other designers from working on the step of the method- 
ology. This occurs in step 1505 of the process, where 

40 other designers are locked out from accessing the same 
step. 

[0158] During execution of "work on this step" in 
step 1507 of the process, the interface and flow control 
tool records tool execution status reports, and other 

45 items. Monitoring task performance provides many ben- 
efits. For example, if simulations using a particular tool 
begin to take an excessive amount of time, a problem 
with the tool or methodology may be indicated. Inquiry 
for the reasons for the long run time might be traced to 

so a need for variations in the methodology for a particular 
design or to a problem associated with a tool. 
[0159] The interface and flow control tool also pro- 
vides for problem reporting. If the designer determines 
that a problem exists in step 1509 of the process, the 

55 designer may choose to access the problem reporting 
page in step 1511 of the process. The methodology 
server notifies other users of the existence of the prob- 
lem in step 1512 of the process, or logs the problem 
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against the block or chip on the design server in step 
1513 of the process. 

[0160] FIG. 26 shows an embodiment of a problem 
report page that is used to report problems encountered 
while engaged in the design process 1900. When a 
problem is found the designer clicks on the problem but- 
ton 1901 shown in this embodiment. The problem but- 
ton in this embodiment appears at the top of every web 
page. Problems may be logged against the tools, meth- 
odologies, blocks or chips. When noted against the 
tools and methodologies, the remote support teams will 
be notified. When problems are logged against blocks 
or chips this embodiment will alert the chip designers of 
problems in the progress of the design. 
[0161] After the problem is logged against a block 
or chip on the design server, the problem tool or meth- 
odology generally must be remotely, i.e., not on this 
server, debugged. For debugging purposes, design 
data files that contain information about the problem are 
needed. Typically, designers manually locate the files 
that are likely to be relevant and bundle them up for 
delivery to developers who are responsible for analysis 
and correction of problems. 

[0162] There may be some problems associated 
with requiring a designer to perform the file gathering 
task. First, the designer may fail to locate one or more of 
the input and output files that are associated with the 
step in which the problem occurred. Second, the 
designer may select some files that are not relevant, 
causing confusion in the debugging process. Third, the 
designer may select the files that have correct names 
but without problem information because the selected 
files have not been taken at the right time to include 
information about the problem. 
[0163] One embodiment of the present invention, 
therefore, includes a new problem reporting process for 
methodology steps that relieves designers from having 
to locate and bundle files that are relevant to the debug- 
ging process. FIG. 27 is a problem reporting process. 
The process in step 1521 allows a designer to mark a 
check box to indicate that data files are to be submitted 
with the problem report when the data files are desired 
along with the problem report. The check box is prefer- 
ably available in a problem report form, which the 
designer fills in and submits for processing. 
[0164] Once the problem report form for a particular 
step is submitted with the marked check box, the proc- 
ess in step 1 523 displays a web page that contains a list 
of all input files and output files associated with the par- 
ticular step. These input and output files include files 
from steps that point to the particular step and files from 
steps that the particular step points to. The process in 
step 1 525 allows the designer to select the files that are 
to be included with the problem report and to deselect 
the files that are not to be included with the problem 
report. 

[0165] The process in step 1527 may give the 
designer an option to save design data files in the local 



server's problem reporting area for archival purposes. 
The process in step 1 527 may also give the designer an 
option to attach the design data files to the problem 
report. The problem report may be sent as an e-mail. 
The process in step 1529 allows the designer to submit 
the form on the web page, having a list of selected and 
deselected input and output files, for processing. 
[0166] The process in step 1531 bundles the input 
and output files that have been selected and com- 
presses them into a file. This bundle of files preferably 
includes chip info and block info files as well. The com- 
pression may be performed as a background task by a 
web server so that there is no timeout associated with 
the web page while waiting for the compression to take 
place. 

[0167] The process in step 1533 performs file sav- 
ing or sending in accordance with options selected by 
the designer in step 1527. If the designer, has selected 
to save the design data files in the local server's prob- 
lem reporting area, then the bundled design data asso- 
ciated with the problem report is saved into the problem 
reporting area and a problem report is e-mailed with 
indication that the bundled design data have been 
saved locally by the web server. 
[0168] If the designer has selected to send the 
design data files as an attachment to the problem 
report, then the bundled design data is attached to the 
problem report and e-mailed. In this case, since the e- 
mail is to contain the bundled design data as an attach- 
ment, a UNIX process is preferably used to bundle and 
compress the design data files and not the web server 
process. Thus, in this case, the UNIX process, and not 
the web server process, preferably e-mails the problem 
report. 

[0169] A bundling engine used for bundling is pref- 
erably a standard UNIX command far, which is in the 
standard location /bin. The tar command is preferably 
not encapsulated into the integrated circuit design and 
fabrication system. 

[0170J A compression engine comprises a com- 
pression executable that is preferably specified to be an 
encapsulated integrated circuit design and fabrication 
tool so that it can be invoked in a machine independent 
manner. This compression engine is to perform the 
compression of bundled design data in the web server. 
The name of the compression engine is preferably 
specified in the web server's configuration file. Thus, by 
modifying the configuration file, compression engines 
other than a standard compression engine may be 
selected. 

[0171] When a problem report with an associated 
bundled design data is displayed, the problem report 
web page preferably includes a download link to the file 
containing the associated bundled design data. A 
designer who has the problem preferably has an option 
to delete the file containing the associated bundled 
design data. 

[0172] Returning now to FIG. 22, in step 1515, the 
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process determines if the designer's design task is fin- 
ished. If it is not finished, he selects the next tool and 
proceeds with the whole process again until finished. In 
other embodiments the designer may have a choice of 
tools whether the tools are from different manufacturers 5 
or different versions of the same tool. This gives the 
designer the freedom to try different tools or different 
versions of the same tool and compare the results 
obtained. When all the design tasks are finished, a 
designer stops work and the progress achieved by the 10 
designer is recorded on the design server. The system 
updates the access list to allow the next designer to log 
in and perform his required part of the design. 
[0173] In addition, various pointers may be used to 
interlink methodologies, steps of methodologies and the 15 
location of the executables for those steps. Another 
alternative embodiment provides guided instructions to 
the designer as part of the methodology to increase the 
ease of execution of steps. In alternative embodiments, 
the methodologies do not all have to reside on the same 20 
methodology server. Work on some blocks may be split 
among several methodology servers. 
[0174] Thus, the present invention can provide a 
software suite supporting a methodologies-based 
approach for the development of large scale integrated 25 
circuits. Platforms are configured as web servers so that 
they may be easily accessed by designers in widely-var- 
ying physical locations and with widely-varying compu- 
ter workstation capabilities. 

[0175] A suite of methodologies is defined for each 30 
block of an integrated circuit. This suite is defined by 
expert designers, through the use of an interface, who 
enter information regarding the steps and tools to be 
used during design of the blocks. The expert designer 
provides whatever documentation deemed appropriate 35 
to aid in completion of the steps. 
[0176] For each block within ah integrated circuit, 
an expert designer attaches a methodology or set of 
methodologies in an ordered fashion to a block. These 
methodologies are then used by block designers to 40 
design and implement the block. 
[0177] The invention provides extensive reporting 
capability regarding the status of development of each 
block, as well as metrics pertaining to the implementa- 
tion of the design. These metrics include, for example, 45 
information pertaining to the run time of various tools, 
the time taken to accomplish each methodology, as well 
as each step in that methodology. 
[0178] The invention also includes a common soft- 
ware interface (CSl). The CSI defines a number of func- so 
tions which are to be supported by each tool used within 
the system. The functions from other tools. 
[01 79] Accordingly, the present invention provides a 
design environment. Although this invention has been 
described in certain specific embodiments, many addi- 55 
tiona! modifications and variations would be apparent to 
those skilled in the art. It is therefore to be understood 
that this invention may be practised otherwise than as 



specifically described. Thus, the present embodiments 
of the invention should be considered as illustrative and 
not restrictive. 

Claims 

1. An integrated design environment for the design 
and test of integrated circuits, the integrated circuits 
being comprised of blocks, comprising: 

a plurality of computers, the computers includ- 
ing a browser for the display of pages including 
forms; 

at least one methodology server connected to 
the plurality of computers by a network, the 
methodology server including a page generator 
generating the pages including forms and addi- 
tionally including programs responsive to sub- 
mission of information, from the computers 
using the pages including forms; and 
at least one compute server connected to the 
network, the compute server including an elec- 
tronic design automation tool, the compute 
server executing the electronic design automa- 
tion tool in response to a request generated by 
a program resident on the methodology server. 

2. The integrated design environment of claim 1, 
wherein the pages including forms include method- 
ology capture pages. 

3. The integrated design environment of claim 2, 
wherein the methodology capture pages include an 
input selection of a step type. 

4. The integrated design environment of claim 3, 
wherein the step type is comprised of a flow step, a 
job step, a file step, a sub-methodology step, a 
branch step, or an information step. 

5. The integrated design environment of claims 1 , 2, 3 
or 4, wherein the network is an intranet. 

6. The integrated design environment of claims 1 , 2, 3 
or 4, wherein the network is the Internet. 

7. The integrated design environment of claims 5 or 6, 
wherein the methodology server and the computers 
communicate using Hypertext Transfer Protocol. 

8. The integrated design environment of any preced- 
ing claim, wherein the pages including forms 
include methodology execution pages. 

9. The integrated design environment of claim 8, 
wherein the methodology execution pages include 
step forming a directed graph. 
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10. The integrated design environment of claim 4, 
wherein an information step is comprised of an exe- 
cutable script. 

11. The integrated design environment of claim 10, 5 
wherein a job step includes an executable configu- 
ration script. 

12. A method of designing blocks using computers for 
use in integrated circuit design comprising: w 

capturing a design methodology, the design 
methodology having steps, the steps including 
sub-methodologies; 

attaching the design methodology to a block; 15 
and 

executing the design methodology for design- 
ing a block. 

13. The method of claim 12, further comprising the 20 
generation of metric data and reports. 

14. The method of claim 12 or 13, further comprising 
the generation of data to generate semiconductor 
masks. 25 

15. A method of designing blocks, the method including 
the association of methodologies with a block, com- 
prising: 

30 

determining the performance requirements of a 
block; 

entering the performance requirements of a 
block into a data base; 

determining methodologies for use in design- 35 
ing the block achieving the performance 
requirements; 

entering the selection of methodologies into a 
centrally located database; and 
executing the methodologies using remotely 40 
located computers. 

16. A web based method for designing integrated cir- 
cuits comprising: 

45 

recording a design methodology that includes 
data management, revision control, data 
accessibility and logistics; and 
providing automated documentation and 
scheduling allowing concurrent engineering by so 
multiple individuals or groups. 

17. A computer system for designing blocks for use in 
an integrated circuit comprising: 

55 

a methodology server storing design methodol- 
ogies; 

a user system linked to the methodology 



server, the user system selecting methodolo- 
gies for a block; and 

a compute server linked to the methodology 
server and the user system, the compute 
server executing a step of a methodology. 

18. The integrated design environment of any of claims 
2 to 4, wherein the methodology capture pages 
include means for making compressible file steps 
and means for selecting a compression engine tool 
used during compression and decompression. 

19. The method of claims 12, 13, or 14, wherein the 
step of capturing a design methodology comprises: 

determining which file steps are candidates for 
automatic compression and decompression; 
marking the determined file steps; and 
specifying in a compression engine a tool to be 
used. 

20. The method of claim 1 9, wherein the step of execut- 
ing the design methodology for designing a block 
comprises: 

compressing compressible files associated 
with the determined file steps if the compressi- 
ble files are not yet compressed 

21. The method of claim 19 or 20, wherein the step of 
executing the design methodology for designing a 
block comprises: 

decompressing compressible files associated 
with the determined filed steps if the compress- 
ible files have been compressed. 

22. The method of any of claims 12 to 14 or 19 to 21, 
wherein the step of executing the design methodol- 
ogy for designing a block comprises: 

editing a file. 

23. The method of claim 22, wherein the step of editing 
a file comprises: 

decompressing the file if the file has been com- 
pressed; 

modifying the file; and 

compressing the file if the file is compressible. 

24. The method of any of claims 12 to 14 or 19 to 23, 
wherein the step of executing the design methodol- 
ogy for designing a block comprises: 

executing a job using an input file to generate 
an output file. 
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25. The method of claim 24 wherein the step of execut- updating the design methodology by modifying 

ing a job comprises: the XML file. 



decompressing the input file; 

executing the job using the decompressed s 

input file to generate the output file; 

compressing the input file; and 

compressing the output file. 

26. The method of any of claims 12 to 14 or 19 to 23, w 
wherein the step of executing the design methodol- 
ogy for designing a block comprises: 

executing a chain job using one or more input 
files to generate one or more output files. 15 

27. The method of claim 26,wherein the step of execut- 
ing a chain job comprises: 

decompressing the one or more input files; 20 
executing a first level chain job; and 
compressing the input files that are not going to 
be used to execute any other level chain jobs. 

28. The method of claim 26 or 27, wherein the step of 25 
executing a chain job further comprises: 

executing a next level chain job; 
compressing the input files that are not going to 
be used to execute any other level chain jobs; 30 
and 

repeating the steps of executing a next level 
chain job and compressing the input files that 
are not going to be used to execute any other 
level chain jobs until the last level chain job has 35 
been executed. 

29. The method of claims 26, 27 or 28, wherein the step 
of executing a chain job further comprises: 

40 

compressing all remaining input files to be 
compressed; and 

compressing all output files to be compressed. 

30. The method of any of claims 12 to 14 or 19 to 29, 45 
wherein the step of capturing a design methodol- 
ogy comprises: 

creating an XML file containing the design 
methodology. so 

31. The method of claim 30, further comprising: 

generating multiple files for executing the 
design methodology using the XML file. 55 

32. The method of claim 30 or 31 , further comprising: 



33. The method of of claim 32,further comprising: 

generating multiple files using the modified 
XML file for executing the updated design 
methodology. 

34. The method of claims 30, 31 , 32 or 33, wherein the 
step of creating the XML file comprises: 

converting multiple files defining the design 
methodology into the XML file. 

35. The method of any of claims 12 to 14 or 19 to 34, 
wherein the step of executing a methodology for 
designing a block comprises: 

reporting problems encountered during execu- 
tion of the methodology. 

36. The method of claim 35, wherein the step of report- 
ing problems comprises: 

indicating that data files are to be submitted 
with a problem- report; 

indicating on a form a required format of the 
problem report; and 

submitting the form to create the problem 
report. 

37. The method of claim 36,wherein the step of indicat- 
ing on a form comprises: 

selecting files that are to be included in the 
problem report; and 

deselecting files that are not to be included in 
the problem report. 

38. The method of claim 36 or 37, wherein the step of 
indicating on a form further comprises: 

checking check boxes for saving design data 
files. 

39. The method of any of claims 36, 37 or 38, wherein 
the step of indicating on a form further comprises: 

checking check boxes for attaching the design 
data files to the problem report. 

40. The method of any of claims 36 to 39, wherein the 
form includes a list of all input and output files. 

41. The method of any of claims 36 to 40, wherein the 
step of reporting problems further comprises: 
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bundling the selected files and compressing 
the selected files into a compressed file. 

42. The method of claim 41 , wherein the step of report- 
ing problems further comprises: s 

saving the compressed file in a local server. 

43. The method of claim 41 or 42, wherein the step of 
reporting problems further comprises: 10 

attaching the compressed file to the problem 
report and sending the compressed file 
together with the problem report. 

44. The integrated design environment of any of claims 
1 to 11, wherein the. programs responsive to sub- 
mission of information from the computers are used 
to generate files that comprise a captured method- 
ology. 

45. The integrated design environment of any of claims 
1 to 1 1, or 44, wherein the program resident on the 
methodology server includes a CGI program for 
requesting the execution of the electronic design 25 
automation tool. 

46. The method of claim 12, further comprising the 
generation of test data. 

30 

47. A design apparatus for the design of integrated cir- 
cuits having blocks, comprising: 

a computer including a browser for displaying 
pages; 35 
a server connected to the computer by a net- 
work, including a page generator generating 
the pages based on design methodology and 
programs responsive to input from the comput- 
ers using the pages and a memory for storing 40 
design methodology; and 
a processor executing design methodology 
stored in the memory. 

48. A computer program containing executable instruc- 45 
tions that, when executed, cause a computer to per- 
form the steps of: 
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capturing a design methodology to a block; 
attaching the design methodology to a block; so 
and 

executing the design methodology for design- 
ing a block. 

49. A computer readable medium on which is stored 55 
the computer program of claim 48. 
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NEW PROBLEM REPORTING PROCESS 

FOR STEPS 
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SELECT CHECK BOX TITLED "SUBMIT 
DATA FILES WITH PROBLEM REPORT" 



DISPLAY A FORM WITH THE LIST OF 
ALL INPUT FILES AND OUTPUT FILES 
ASSOCIATED WITH THE STEP 



I 



SELECT / DESELECT FILES TO BE 
INCLUDED / NOT INCLUDED IN THE 
PROBLEM REPORT 



CHECK THE CHECKBOXES FOR 
OPTIONALLY SAVING AND ATTACHING 
DESIGN DATA FILES, RESPECTIVELY 



SUBMIT THE FORM WITH THE LIST 
OF ALL INPUT AND OUTPUT FILES 



BUNDLE CHECKED FILES AND COMPRESS 
THEM INTO A FILE. 
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SAVE IN LOCAL SERVER OR SEND DESIGN 
DATA ACCORDING TO SELECTED OPTION 



c 



1521 



1523 



1525 



1527 



1620 



1531 



1533 



RETURN 



FIG. 27 



48 



EP 1 063 599 A2 



GO 

CM 



o 

z: 

< 
— i 

CL 

cr 

UJ 

o 

Q_ 



o 
z 



< 

Qd O 

UJ ,-J 

a. q_ 
I >- 

LJ I — 

to 

Ld 

< 
2 



Z 
O 



2 
Ld 

O 

o 
o 



o 

ft! 

c> 

CO 

© 

a, 

© 



± 3 

CO L_ 



g LU 

> X 
►— 

o 

LJ CXL 

5 

a z 

CO ^ ^ 

— a. 



o 
O 
-j 
00 

Ld 
X 
\- 

£T 
O 



3 
O 
>- 
< 
_i 

>- 
_j 

a. 
a 

D 
LO 

QtL 
Ld 
^ 
O 
a. 

u. 
O 

Ld 

o 
< 

2 



CO 

or 

O Ld 
2 g 

O UJ 
° S 

o o 

UJ < 
— Q 

9= 5 

X O 
O CD 

< CO 
UJ 

i — E 
o uj 



<r- CM 



OS 

•© 
o 

Co 

3 

a; 
© 

CO 

© 

Co 




49 



EP 1 063 599 A2 



FIG.29 



r 



2413 



INTRANET| |^-2401 
|2405-~- ~f 

is ! , 



NETSCAPE, 
INTERNET 
EXPLORER 



I 



2415 < 

NETSCAPE. 
INTERNET 
EXPLORER 



L 

r 



2417 JJ 

NETSCAPE. 
INTERNET 
EXPLORER 



<FIREWALL> 
2407 



INTERNET 



I 



.J 



INTRANET 



2413 

NETSCAPE, 
INTERNET 
EXPLORER 




<FIREWALl> 
2411 



2415 



NETSCAPE. 
INTERNET 
EXPLORER 



L 



o — o 



2417 , 

NETSCAPE, 
INTERNET 
EXPLORER 



<F!REWALL> 
2409 



H^-2403 



2413 

NETSCAPE, 
INTERNET 
EXPLORER 



2415 



NETSCAPE, 
INTERNET 
EXPLORER 



■i 



FACTORY 
2425 



LIBRARIES/ 
TOOLS 
2427 



2400 |_ 



. 2417 

NETSCAPE, 
INTERNET 
EXPLORER 




50 



EP 1 063 599 A2 



JOB STEP EXECUTION 



c 



START 

~T~ 



SET UP GENERAL PURPOSE 
ENVIRONMENT 



EXECUTE METHODOLOGY SERVER 
ENVIRONMENT FILE 



PUT IN ENVIRONMENT CODE FOR 
METHODOLOGY JOB STEP 



STATUS OF JOB SET TO 
READY TO RUN 



BUILD COMMAND LINE 



SCRIPT GIVEN TO COMPUTE SERVER 



RETURN 



3 



51 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europ6en des brevets 



(12) 



(88) Date of publication A3: 

08.10.2003 Bulletin 2003/41 

(43) Date of publication A2: 

27.12.2000 Bulletin 2000/52 

(21) Application number: 00303662.1 

(22) Date of filing: 02.05.2000 



(n) EP1 063 599 A3 

EUROPEAN PATENT APPLICATION 

(51) IntCI. 7 : G06F 17/50 



(84) Designated Contracting States: 


(72) Inventor: Dole, Harry 


AT BE CH CY DE DK ES Fl FRGB GR IE IT U LU 


San Jose, California 951 1 2 (US) 


MC NLPTSE 




Designated Extension States: 


(74) Representative: Stebbing, Timothy Charles 


ALLTLVMKROSi 


Haseltine Lake & Co., 




Imperial House, 


(30) Priority: 20.06.1999 US 140528 


15-19 Kingsway 


06.01.2000 US 478978 


London WC2B 6UD (GB) 


(71) Applicant: FUJITSU LIMITED 




Kawasaki-shi, Kanagawa 21 1-8588 (JP) 





CO 

< 

O) 
O) 
lO 

CO 
CO 

o 



Q. 
LU 



(54) System and method for integrated circuit design 



(57) A software suite supporting a methodologies-' 
based approach for the development of large scale in- 
tegrated circuits. Platforms are configured as web serv- 
ers (2503) so that they may be easily accessed by de- 
signers in widely-varying physical locations and with 
widely-varying computer workstation capabilities. 

A suite of methodologies is defined for each block 
(101, 103, 105, 107, 109, 111) of an integrated circuit 
(1 00). This suite is defined by expert designers, through 
the use of an interface, who enter information regarding 
the steps and tools (2300-2306) to be used during de- 
sign of the blocks (101, 103, 105, 107, 109, 111). The 
expert designer provides whatever documentation is 
deemed appropriate to aid in completion of the steps. 

For each block (101,1 03, 1 05, 1 07, 1 09, 1 1 1 ) within 
an integrated circuit (100), an expert designer attaches 
a methodology or set of methodologies in an ordered 
fashion to a block ( 1 01 , 1 03, 1 05, 1 07, 1 09, 1 1 1 ) . These 
methodologies are then used by block designers to de- 
sign and implement the block. 

The invention provides extensive reporting capabil- 
ity regarding the status of development of each block, 
as well as metrics pertaining to the implementation of 
the design. These metrics include, for example, infor- 
mation pertaining to the run time of various tools, the 
time taken to accomplish each methodology, as well as 
each step in that methodology. 

The invention also includes a common software in- 
terface (CSI). The CSI defines a number of functions 
which are to be supported by each tool (2300-2306) 



used within the system. The functions allow other tools 
within the system to access data or information from oth- 
er tools. 
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